יישום פרקטיקות של הנדסת מערכות בחברות אזרחיות קטנות ובינוניות מפגש 1: תהליך הנדסת מערכות עקרונות, תפיסה, הנדסת מערכות מבוא וסקירה כללית Systems Engineering Overview מרכיבים פרופ' מוטי פרנק HIT-Holon Institute of Technology כל הזכויות שמורות למוטי פרנק מכון טכנולוגי חולון HIT
חזרה מושגי יסוד בניהול פרויקטים
מהו פרויקט? העבודה בכל ארגון כרוכה בתפעול ובפרויקטים: פרויקט הוא מאמץ חד פעמי להשגת מטרות מוגדרות מראש )כמו למשל מוצר או שירות חדש( המתבצע תחת אילוצים )כמו למשל אילוצי זמן ותקציב(. תפעול הינו העבודה השוטפת והחוזרת על עצמה. כשפרויקט מסתיים, הצוות מתפזר והתוצר עובר לתפעול שוטף. ייצור סדרתי ייצור כמות מוגבלת של מוצרים זהים )ייצור מכשירי קשר לצה"ל(. ייצור המוני ייצור בכמויות גדולות )קוקה קולה ייצור פחיות שתייה(.
ממצאי מחקר מ- 2001 בארה"ב נתונים דומים נמצאו בעשרות מחקרים אחרים 23% מהפרויקטים נכשלו טוטלית ובוטלו לפני סיומם. 49% מהפרויקטים הצליחו באופן חלקי )הסתיימו אך לא עמדו בתקציב ו/או בלו"ז ו/או בתכולה(: בלמעלה מ- 20% מהפרויקטים הייתה חריגה של יותר מ- 100% בתקציב ו/או בלו"ז. רק 7.3% ענו ב- 100% 28% מהפרויקטים הצליחו. על דרישות הביצועים.
מדוע זה קורה? )רשימה חלקית( דרישות לא מובנות; אי הקפאת דרישות; שינויים; אי עמידה בלו"ז עקב צורך בעבודה חוזרת )Rework( כתוצאה מטעויות תיכון; לחץ הלקוח לקצר.TTM דרישות סותרות לרמת ביצועים )תכולה(, עלויות ולוחות זמנים )"המשולש הקדוש"(. צלע רביעית שביעות רצון הלקוח; בעלי עניין עם אינטרסים מנוגדים; צלע חמישית איכות. ריבוי דיסציפלינות טכנולוגיות; שילובי חומרה- תוכנה; הרבה מאוד אפשרויות ושיקולי בחירה; חלוקת עבודה תוך מו"מ ופשרות; אינטראקציות בלתי צפויות והפרעות הדדיות; חוסר תיאום בין המעורבים )אצלנו, אצל הלקוח ובין בעלי עניין שונים(. אי ודאות הקשורה למידת החדשנות הטכנולוגית, ביחס לסביבה המשתנה, בזמנים הדרושים, בעלויות, במשאבים, ובתנאי הסביבה )לדוגמה: מזג אויר, עלית המדד, טיב החומרים שהתקבלו, רמת השכר במשק(. תכולת עבודה גבוהה ולרוב תכנון וביצוע מורכבים ומסובכים. כוח האדם המתאים לא תמיד זמין. אילוצי עלות ולוחות זמנים מוכתבים מבחוץ. ביצועים )performance( עלות לו"ז
ריבוי בעלי העניין בפרויקט )Stakeholders( הארגון המבצע. לרבות כל מחלקות התמיכה כגון רכש, שיווק, מכירות, הדרכה, שינוע, ייצור, מרכיבים, בודקים, מחסנאים, אנשי תחזוקה ועוד. מנהלי הפרויקט בחברה ושל הלקוח. צוות הפרויקט. קבלני משנה. שונים רשויות, חוקים, תקנים, עובדים אחרים, תורמים, ספקים, כלי תקשורת, ארגוני שדולה, הקהילה ועוד. הלקוח )המזמין( האדם/ארגון/משרד ממשלתי שמשלם עבור הפרויקט. לרבות המשתמש הסופי, מגדיר הדרישות, מאשר אבני דרך, הגוף הרוכש, הגוף המשלם.
יש צורך בעבודה שיטתית ומאורגנת לאור הנתונים "העגומים" בנוגע להצלחת פרויקטים התפתחה עם השנים מתודולוגיה )גישות וטכניקות( בשם: "ניהול פרויקטים" שניתן להפעילה על סוגים שונים של פרויקטים ושמטרתה להגדיל את ההסתברות שהפרויקט יסתיים בהצלחה. ניהול פרויקטים הוא יישומם של ידע, מיומנויות, כלים וטכניקות לביצוע פרויקט כך שיעמוד בדרישות.
תשעת תחומי הניהול בניהול פרויקטים עפ"י המדריך PMBOK Project Management Body of Knowledge שפורסם ע"י ה- Institute )www.pmi.org( PMI Project Management ניהול האינטגרציה )Integration( הכנת תוכנית עבודה לפרויקט וביצועה תוך מעקב ובקרה. ניהול תכולת הפרויקט )Scope( הכנת מסמך ייזום Chart(,)Project הגדרת הצורך והדרישות, הגדרת תכולת העבודה בפרויקט. ניהול לוחות הזמנים )Time( הגדרת פעילויות, סדר ביצוען, משכן, מועד התחלתן וסיומן ובקרת לו"ז. ניהול העלויות )Cost( תכנון, הערכת, תקצוב ובקרת עלויות. ניהול האיכות )Quality( תכנון האיכות, הבטחת איכות assurance(,)quality בקרת איכות. ניהול משאבי אנוש Resources( )Human תכנון ומבנה ארגוני, השמת עובדים, פיתוח צוות. ניהול ידע, מידע ותקשורת )Communication( הגדרת צרכי המידע והתקשורת, הפצת המידע, דיווחים. ניהול סיכונים )Risk( תוכנית ניהול סיכונים, זיהוי סיכונים, ניתוח, מענה, בקרה ניהול רכש )Procurement( זיהוי צרכי רכש, בקשת הצעות, קבלת הצעות, בחירת ספקים, ניהול חוזים.
שלבי פרויקט לפיתוח וייצור מוצר מדף חדש מחזור החיים של מוצר/מערכת ייזום תכנון ביצוע בדיקות )ייצור סדרתי( תפעול שוטף דוגמאות: בניית בית, פיתוח מוצר מדף כמו מדפסת/מצלמה/מכונית חדשה
הגדרת תכולת העבודה בפרויקט מסמך ה- SOW Statement Of Work נקרא לפעמים Scope Statement ולפעמים תוכנית פרויקט The Project Plan תיאור כללי של הפרויקט, הצרכים, תיאור כללי של תכולת העבודה הנדרשת לרבות: הסיבות לו, מטרותיו ויעדיו, תיאור כללי של השיטה בה צריך הקבלן לבצע את התכנון והפיתוח; תיאור כללי של הניסויים והבדיקות שיבוצעו במהלך הפרויקט ובסיומו. תיאור כללי של ההדרכה, רשימת תיעוד ודוחו"ת נדרשים. רשימת התוצרים שיסופקו ההטמעה והתמיכה לאחר הסיום. Deliverables אופן ניהול הפרויקט, מבנה ארגוני, איוש, בעלי עניין. הגישה הטכנולוגית. חלוקת אחריות וסמכות, מחויבויות הלקוח. פרק כלכלי עלויות, מקורות כספיים, אילוצים, מועדי תשלום לקבלן. מתכונת הטיפול בשינויים. לוחות זמנים ואבני דרך. תוכנית לניהול סיכונים. הפניה למפרטים הטכניים. מדדים להערכת מידת ההצלחה של הפרויקט.
הגדרת תכולת העבודה בפרויקט WBS Work Breakdown Structure כלי עזר להגדרת התכולה והדרישות. מפרקים את הפרויקט ל: חבילות עבודה מפרקים כל חבילת עבודה לפעולות שביצוע כולן פירושו השלמת ביצוע חבילת העבודה. עד מתי ממשיכים לפרק? עד שמגיעים לפעולות שלא כדאי לפרקן יותר פעולות להן תפוקה מוגדרת המתוארות הניתנת לביצוע ע"י אדם/צוות אחד. כמה פעולות בחבילת עבודה אחת? בד"כ בהיקף מצטבר של 500 שעות עבודה או משך מצטבר של 20 ימי עבודה. צריך לבדוק שאכן ביצוע כל הפעולות וחבילות העבודה מביא למימוש כל הדרישות הפונקציונליות והטכניות מהפרויקט. אפשר להציג WBS בטקסט, כמו תוכן עניינים מדורג, או בשרטוט.
הצורך בהנדסת מערכות
הצורך בהנדסת מערכות ככל שהפרויקטים נעשים גדולים, מורכבים, מסובכים ורב- תחומיים, ובמקביל לחלוקת העבודה בין גורמים שונים, כך הולך וגובר הצורך ב: מקצוע הנדסי-ניהולי אשר יטפל באינטגרציה ותאום בין: כל מרכיבי המערכת הגופים ההנדסיים בפרויקט מהנדסים בעלי יכולת ראייה מערכתית ה"רואים" את השלם. )ראייה מערכתית = Thinking )Systems ניסיון לתת מענה לבעיות שהוזכרו לעיל בחזרה על ניהול פרויקטים ולכל הבעיות שבגללן פרויקטים נכשלים.
הניהול בפרויקטים טכנולוגיים רחבי היקף ניהול פרויקטים הנדסת מערכות הניהול בפרויקטים טכנולוגיים מורכבים מתבצע בשני רבדים: ניהול פרויקטים הנדסת מערכות להיבטים ההנדסיים. מנהל הפרויקט נושא באחריות הכוללת לכל ההיבטים. מהנדס המערכת הראשי נושא באחריות הכוללת מנהל תוכנית מהנדס מערכת ראשי מנהל חוזה ראש צוות דיסציפלינארי ראש צוות דיסציפלינארי מנהל תוכנית משנה מנהל תוכנית משנה
פרויקט החץ אורן ירוק מכ"מ בקרת האש, פותח ויוצר באלת"א אתרוג זהב מרכז שליטה ובקרה, פותח ויוצר בתדיראן אגוז חום תקשורת למכ"מ ולמשגרים מנ"י קרון מרכז ניהול היירוטים משגר משאית להובלת 6 זבילים טיל חץ 2 טיל בעל שני שלבים, ראש ביות, ראש קרבי, כוונת אלקטרו-אופטית ותקשורת.
Overall VoIP Solution Architecture OSS IP Enhanced Services IN Services PSX Local Services -Routing -Voice VPN -LCR -8xx Numbers, GSX NBS InsightEMS PSX IP Network SGX ASX ASX- #5 Services GSX NBS National Carriers International Carriers Mobile Carriers National Carriers International Carriers Mobile Carriers Carriers with Bilateral Agreement Media Gateway SGX Circuit Circuit VOIP Carriers Media Gateway NBS : Carriers with Bilateral Agreement -Hide Network Topology -Interworking Requirements -Transcoding -Services -Bandwidth and QOS policing Media Gateway Circuit Circuit
הגדרת הנדסת מערכות
הגדרת המושג מערכת אוסף של מרכיבים, המאורגנים כך שיוכלו לפעול כשלם להשגת יעדים ומטרות מסוימות ואשר קיימים בו קשרי גומלין ותלות הדדית בין מרכיביו. A combination of interacting elements organized to achieve stated purposes.
הגדרת הנדסת מערכות )עפ"י )INCOSE Systems Engineering SE is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.
עוד הגדרות להנדסת מערכות מקצוע-על, הנדסי וניהולי, הכולל כלים, טכניקות ומתודולוגיות שמטרתו לבצע אינטגרציה כך שכל מרכיבי המערכת יעבדו ביחד בצורה האופטימלית ביותר כמערכת אחת שלמה. An interdisciplinary approach and means to enable the realization of successful systems.
הנדסי הגדרת צורך; הגדרת הדרישות; תכן על מקצוע הנדסי-ניהולי הגדרת משימה; ניתוח דרישות )Preliminary Design( ניהולי ניתוח פונקציונלי הגדרת ארכיטקטורה )תכן לוגי( )תכן פיזי( תכן מפורט Design( )Detailed אינטגרציה, בדיקות, אימות ותיקוף ניתוחים מערכתיים בניית והובלת צוותים קביעת שיטות, כלים ותהליכים ניהול הנדסי של הפרויקט/תוכנית הגדרת מערכת בקרה הנדסית ותיאומים בכל שלבי הפרויקט
תפקידי הנדסת המערכת בפרויקט )1( הערה: ברמה העליונה, המהנדס הראשי של התוכנית )או סגן טכני למנהל התוכנית( הוא מהנדס מערכות. אדם זה גם אחראי בד"כ על כל מהנדסי המערכות העובדים בתוכנית. אבל, מהנדסי מערכות משולבים בכל הרמות ובכל המחלקות שיווק, תיכון, ייצור, בדיקות. התפקידים: ה"דבק" שמחבר את מרכיבי המערכת. מורידים מ"למעלה למטה" את הפרספקטיבה המערכתית. מעלים מ"למטה למעלה" בעיות וצרכים לשינויים מערכתיים. בדיונים מהנדסי המערכת מייצגים את ראש הפרויקט/מנהל התוכנית בהיבט ההנדסי הכולל.
תפקידי הנדסת המערכת בפרויקט )2( ראייה כוללת של התוכנית overall perspective תיאומים בין צוותי ההנדסה השונים מעורבות בכל שלבי הפרויקט )מהשיווק והגדרת המערכת, דרך התיכון ועד המסירה והתמיכה( קשר רציף עם הלקוח ביצוע trade-off studies בחינת הצעות לשינויים ובדיקת ההשלכות הכוללות
תפקידי הנדסת המערכת בפרויקט )3( הגדרת מטרות המערכת system objective )צרכי הלקוח( ניתוח והגדרת דרישות requirements analysis השוואה בין חלופות, ניתוחי עלות-תועלת cost-benefit analysis בחירת חלופה העונה על דרישות הלקוח. הפעלת שיקולים מערכתיים tradeoff analysis ניתוח פונקציונלי functional analysis תיכון על preliminary design תיכון הארכיטקטורה של המערכת architecture design הכנת אתרי האינטגרציה והבדיקות אינטגרציה ותיכון ממשקים integration; interface design ניתוח מערכתי ובקרה system analysis and control בדיקות ואימות המערכת verification and validation
מיהו מהנדס המערכות? כל המהנדסים צריכים לדעת עקרונות בהנדסת מערכות אך יש מהנדסים המוגדרים בשם זה. סקר בבריטניה: כ- 12,000 מהנדסים צריכים ידע בהנדסת מערכות, רק חלקם מוגדרים כמהנדסי מערכות. בדרך כלל לוקח כמה שנים של עבודה כמהנדס עד שצוברים את הידע, הניסיון וההכרה כמהנדס מערכות מומחה.
מי עוסק בהנדסת מערכות? בעלי התפקידים הבאים: ראשי פרויקטים/ראשי תוכניות מהנדס מערכת ראשי, מנהלי מוצר/מהנדסי שיווק מהנדסי אינטגרציה מהנדסי מערכות מהנדסי מערכת מעורבים בכל שלבי הפרויקט ובכל רמות התפקידים.
הבינלאומי להנדסת מערכות הארגון INCOSE International Council On Systems Engineering נוסד בארה"ב ב- 1992. כיום 50 סניפים ברחבי העולם )כולל סניף בישראל( באתר ניתן למצוא מסמכים רבים בנושאי הנדסת מערכות כשהעיקרי הינו "ספר עזר למהנדס המערכת" Handbook Systems Engineering
מחקר בהנדסת מערכות )נוסף על התוכניות לתואר שני ושלישי( שת"פ בין USC ו- Stevens Institute of Technology הביא להקמת גוף מחקר המקיים כנס שנתי שכותרתו:.Conference on Systems Engineering Research כנס שנתי בו מוצגים חידושים וממצאי המחקרים האחרונים בתחום. קיימים מס' ג'ורנלים מערכות. הבולט: referee Systems Engineering העוסקים בהנדסת
עקרונות יסוד בהנדסת מערכות
עקרונות יסוד בהנדסת מערכות )1( הנדסת מערכות הינה תהליך איטרטיבי התכן )design( מלמעלה למטה )למשל,.Top-Down עדכון דרישות מתמיד(. מסתכלים קודם על התמונה הכוללת לפני שיורדים לפרטים, כלומר, קודם מגבשים קונספט כולל ומבצעים תיכון על ורק אח"כ תיכון מפורט. השילובים והבדיקות מלמטה למעלה.Bottom-Up תמיד יש מספר חלופות/אלטרנטיבות )דוגמה לטכניקת בחירה עץ החלטות(. ולבחינתן יש לבצע trade-study האילוצים מחייבים פשרות.Trade-Off ברמה הטכנית, ברמה הטכנו-מבצעית וברמה הטכנו-כלכלית. משולש האילוצים: תכולה/ביצועים עלויות התיכון לאופטימום ולאו דווקא למקסימום לוחות זמנים. )באנגלית: )Cost-effective
עקרונות יסוד בהנדסת מערכות )2( לא מספיק שכל מחלקה תדאג למוצר שבאחריותה ולאופטימיזציה אצלה: מערכת אופטימלית מורכבת ממספר תת מערכות שאינן בהכרח אופטימליות; ולהפך, כאשר מבצעים אופטימיזציה בתת מערכות אין זה אומר שהמערכת שתורכב מהן תהיה אופטימלית; צריך לבצע את תהליך האופטימיזציה על המערכת השלמה. Departments focused on the optimization of their primary products and often lost sight of the overall system. Each department perceived that their part must be optimal, using their own disciplinary criteria, and failed to recognize that all parts of a system do not have to be optimal for the system to perform optimally. העבודה נעשית בצוותים אינטרדיסציפלינריים: The SE process should be viewed as a major effort in management of teams of experts that lack a common paradigm and a common language but must work together to achieve a common goal.
רמות היררכיה מערכת )System( מרכיב תת מערכת )Element( )Subsystem( מערכת בקרה אווירית. מגדל הפיקוח; מטוס. מע' מורכבת למשל מרדיו, מגבר אנטנה, מגבר הספק. אנטנה, מכלול תת מכלול )Assembly( "קופסה" )Subassembly( רכיב )component( מעגל מוכלל קשר במטוס. קופסת בקרה בתא הטייס. למשל: הרדיו. מודול המקלט. )ג' קו (. הגלאי. חלק )Part( טרנזיסטור, נגד, קבל, סליל, וכד'.
מערכת מערכת בקרה אווירית אלמנט 1 מגדלי פיקוח אלמנט 2 מטוסים אלמנט 3 מרכז שליטה ארצי תת מערכת ניווט תת מערכת 5 הידראוליקה 4 תת מערכת 3 קשר תת מערכת 2 מנוע תת מערכת 1 חשמל מכלול 1: הפעלה מכלול 2: מגבר הספק רדיו מכלול 3: תת מכלול 1: משדר תת מכלול 2: מקלט
כדאיות ההשקעה בהנדסת מערכות
ממצאי מחקרים כדאיות ההשקעה בהנדסת מערכות כדאי להשקיע בשלבים הראשונים של הפרויקט משום ששלבים אלה קובעים במידה רבה מאוד את ההמשך )ראו גרף בשקף הבא(. כמה להשקיע? מומלץ שבשלבים הראשונים יושקע לפחות 30% מתקציב ההנדסה בתהליכי הנדסת מערכות. השקעה נמוכה יותר מעלה את ההסתברות לבעיות אשר עלולות לגרום לפיגורים בלו"ז, הוצאות כספיות ניכרות, ויתור על ביצועים מסוימים או אף להפסקת הפרויקט.
תקן ISO/IEC15288
Enablers הגדרת המושג תהליך Controls Inputs Set of interrelated or interacting activities that transform inputs into outputs Outputs
תהליכי הנדסת מערכות עפ"י ISO/IEC15288 ארבע קבוצות של תהליכים: Technical processes Project processes Project management processes Project support processes Organizational project-enabling processes Agreement processes
תהליכי הנדסת מערכות בפרויקט עפ"י ISO/IEC15288 )שקף 1 מ- 4 ( Technical Processes: 1. Stakeholder requirements definition 2. Requirements analysis 3. Architectural design 4. Implementation 5. Integration 6. Verification 7. Validation 8. Transition 9. Operation 10. Maintenance 11. Disposal
תהליכי הנדסת מערכות בפרויקט עפ"י ISO/IEC15288 )שקף 2 מ- 4 ( Project Processes: Project Management Processes 12. Project Planning 13. Project Assessment 14. Project Control Project Processes: Project Support Processes 15. Decision Management 16. Risk Management 17. Configuration Management 18. Information Management
תהליכי הנדסת מערכות בפרויקט עפ"י ISO/IEC15288 )שקף 3 מ- 4 ( Organizational project-enabling processes: 19. Life-cycle model management 20. Infrastructure management 21. Project portfolio management 22. Human resource management 23. Quality management
תהליכי הנדסת מערכות בפרויקט עפ"י ISO/IEC15288 )שקף 4 מ- 4 ( Agreement Processes: 24. Acquisition 25. Supply
דוגמאות לכלים ממוחשבים בהנדסת מערכות )חלקם ייסקרו בפירוט בהמשך הסדרה(
תוכנות להנדסת מערכות דוגמאות )בנוסף לעשרות כלי פיתוח תוכנה )CASE: Computer-Aided Software Engineering שם התוכנה פונקציות עיקריות דוגמאות למשתמשים Vendor מעקב דרישות אל-אופ Doors IBM (Telelogic) מעקב דרישות, מודלים, תכן על-ניתוח פונקציונלי מלמ Core ViTECH www.vitechcorp.com BAE Systems Motorola Lockeed Martin Northrop Grumman NASA מעקב דרישות, מודלים, תכן על-ניתוח פונקציונלי SysML ARTiSAN
בחירת מודל מחזור חיים בחירת אסטרטגית פיתוח SDLC System Development Life Cycle
בחירת מודל מחזור חיים=בחירת אסטרטגית פיתוח 3 אסטרטגיות פיתוח על פי :Mil-Std 498 Grand Design פיתוח מסודר בצעדים: הגדרת צרכי הלקוח/משתמש, הגדרת הדרישות מהמערכת, תכן על ומפורט, בניית אב טיפוס, בדיקות, ייצור סדרתי. בניית - Incremental הגדרת צורכי הלקוח/משתמש והגדרת הדרישות מהמערכת. בניית דגם ראשוני העונה רק על חלק מהדרישות, בדיקות, דגם 2, בדיקות וכך הלאה עד לבניית ואישור א.ט. סופי. Evolutionary הצרכים לא לגמרי ידועים ולכן הדרישות לא לגמרי סגורות. בונים דגם ראשוני על בסיס מה שיודעים, בודקים ומעדכנים דרישות, בונים דגם 2 ושוב בודקים ומעדכנים דרישות וכך הלאה.
Grand Design
פיתוח מערכת בפרויקט "תפור" טכנולוגי ביטחוני )ניתן ליישום בכל פרויקט "תפור"( זיהוי צורך/בעיה/ רעיון/סקר שוק. התוצר: מסמך צורך/משימה/קונספט מבצעי/תיפעולי )המהווה אפיון לביצוע בדיקת היתכנות(. נקרא לעיתים:.ORS Operational Requirements Statement ביצוע בדיקת היתכנות לבדיקת משמעויות: היתכנות טכנולוגית, עלויות, לוחות זמנים, משאבים דרושים, השפעות חברתיות וסביבתיות. התוצר: בחירת חלופה,RFP מספר חלופות למימוש. התוצר: מפרט דרישות פונקציונליות מערכת גרסת baseline )לפעמים נקרא אפיון פונקציונלי, או מסמך דרישות לקוח ברמת מערכת.SRD בצה"ל: דמ"צ-דרישה מבצעית(, הקצאת תקציב, הגדרת לו"ז. הערה: בתלות בסוג הפרויקט מכינים לעיתים גם מסמך דרישות תפעול.ORD מכרז, חוזה = +SOW )ORD( + SRD ******************************************************************* עדכון ה- ORS והרחבתו למסמך קונספט מבצעי/תיפעולי OCD-Operational Concept Document בנייה/פיתוח: עדכון/אישור ה- SRD, ו"תרגומו" למפרט מערכת System/Subsystem Specification-SSS )זהו מפרט טכני דרישות טכניות ברמת מערכת בשפת הלקוח(. הכנת מפרט ממשקים חיצוניים.IRS "תרגום" ה- SSS למסמכי דרישות תכן ( Description )SSDD-System/Subsystem Design בשפה של מהנדסים הן ברמת מערכת והן ברמת מרכיבי המערכת. הכנת מפרטי ממשקים פנימיים. עדכון.ORD תכן על Design( )Preliminary הכולל ניתוח פונקציונלי )לוגי( ותכן ארכיטקטורה )פיזי(. תכן מפורט Design(.)Detailed התוצר: אב-טיפוס/גרסה 1.0 אינטגרציה, בדיקות, אימות ותיקוף ניסויים ובדיקות של אב הטיפוס/גרסה 1.0 ייצור סדרתי הדרכה, ספרות תפעולית וטכנית, תפעול שוטף, תחזוקה, תמיכה, לוגיסטיקה, שדרוגים; הוצאה משרות.
מודל מפל המים לתיאור שלבי פרויקט מו"פ Feasibility Analysis Design Implementation Test Maintenance System Requirements System Design Detailed Design Implementation+Test Detailed Design Implementation+Test Detailed Design Implement.+Test System Test Qualification Test
מודל ה- V לתיאור שלבי פרויקט מו"פ Define User Needs Validation/Operational Test שדה System Operational Verification Define System Requirements Validation/Test מעבדה System Performance Verification Allocate System Functions to Subsystems Validation/Test מעבדה Verification of Subsystems Detail Design of Components הקפאת תכנון Test מעבדה Verify Components
יתרונות וחסרונות של עבודה לפי מודל ה- V מודל ה- V הינו הנפוץ ביותר כיום בפרויקטים מערכתיים בהם הפיתוח מתנהל בשלבים מסודרים. למודל חשיבות רבה בהדגשת עקרונות מפתח בהנדסת מערכות. החיסרון של עבודה לפי מודל זה הוא שהפעם הראשונה, בהם המפתחים והלקוח יכולים ל"נגוע" במערכת עובדת, הינה בשלב מאוחר מאוד.
שלבי מחזור חיים לפי תקן ISO/IEC 15288
מודל 22 III השלבים של ה- DoD )מופיע בצורה דומה גם ב- Model )DoD 5000 Acquisition לפעמים פאזה זו מופרדת לשתי פאזות PHASE 0 I Program Definition II DEVELOPMENT Eng. Development System Development III. Production, Deployment IV. Operation and Support תכן על Concept Exploration Concept Development 17. ייצור סדרתי, בדיקות קבלה 18-19. תפעול שוטף ובדיקות שוטפות.20.21 תמיכה ושדרוגים הוצאה משרות.11 22. תכנון מערכת מחליפה תכן מפורט 12.פיתוח תת מערכות.13.14.15 ניהול סיכונים אינטגרציה בדיקות א.ט. 6. עדכון 2 ו- 3 לגבי הנבחרת 7. אלוקציה לתת מערכות 8. תכן על מע' )preliminary( 9. א.ט. ראשוני, הדגמות ובדיקות 10. שיקולי ייצור ותמיכה 16. אישור לייצור סדרתי הגדרת הצורך: 1. ניתוח מערכתי של הצורך 2. הגדרת הדרישות 3. תכן ראשוני של הקונספט בדיקת היתכנות: 4. היתכנות טכנולוגית 5. משמעויות )לכל אחת מהחלופות( תקציב, לו"ז ועוד; המלצה על חלופה
הדור ה"חדש" של המודלים מודלים לקיצור TTM Time To Market בפרויקטי תוכנה: Agile Development, Scrum Methodology
מודל הספירלה תאור עקרוני יעיל כאשר: הדרישות מגיעות ב"פעימות" )ולא רוצים לחכות שהכול יהיה סגור מראש(. ניתן להתקדם בצעדים קטנים, כל פעם מוסיפים קצת. לא יודעים איך להתחיל. נדרש לבצע שינויים ותוספות קטנות למשהו קיים. נדרשת גמישות רבה לשינויים. מספרים אופיניים: 5 איטרציות, כל איטרציה 4 שבועות.
מודל הספירלה תאור מורחב כל איטרציה מחזורית כוללת: הגדרת דרישות ניתוח סיכונים בניית דגם סימולציה, ניתוח השוואתי בדיקות בניה, תכן, תכנון המחזור הבא )אם יש(
מודל אב-טיפוס מודל ניסוי וטעייה - Models Prototyping פיתוח מהיר של דגם ראשון ושכלולו עד לקבלת המוצר הסופי. תאור השלבים מתוך: בשקף הבא. http://www.cs.uwlax.edu/~zheng/cs741summer05/lecture2.ppt#2 היתרונות כבר בשלבים מוקדמים ניתן: לזהות בעיות פוטנציאליות. להדגים Mock-up ללקוח. לקבל משוב מהלקוח/משתמש. להבין טוב יותר את מה שנדרש לתכן.
Build and Fix
מודל שן מסור Requirements Analysis Demo Prototype 1 Demo Prototype 2 Qualification Test Integration Test Unit Test System Design Program Design Implementation
Lean Engineering הנדסה/פיתוח/ניהול "רזה" פיתוח רזה מתבסס על שלבי עבודה קצרים )איטרציות( שבכל אחד מהם חברי הצוות עובדים למען השגת יעדיהם ובודקים את עמידתם בהתחייבויות. שבעת העקרונות לפיתוח/ניהול רזה: בטל בזבוז Eliminate Waste )בזבוז: כל מה שלא מייצר ערך ללקוח, מלאי לא נחוץ, המתנה וכד'(. למידה ארגונית: שיתוף העובדים, מערכת משובים מלקוחות ועובדים. קבלת החלטות בנקודות הזמן המאוחרות ביותר האפשריות ועל בסיס עובדות מוצקות ככל האפשר. ספק מהר ככל האפשר Deliver ASAP להעצים את הצוותים: לתת תחושה של שייכות, ביטחון, צוות מנצח, הכרה. הייה לויאלי ללקוח. ראה את התמונה הכוללת. מקור בעיות שורש במערכת. חשוב להתמקד לא רק בצוות ספציפי אלא בביצוע הכולל.
בפרויקטי תוכנה: Agile Development, Scrum Methodology Scrum http://he.wikipedia.org/wiki/scrum Agile http://en.wikipedia.org/wiki/agile_software_development http://he.wikipedia.org/wiki/%d7%a4%d7%99%d7%aa%d7%95%d7%97_%d7%aa%d7%9 5%D7%9B%D7%A0%D7%94_%D7%96%D7%A8%D7%99%D7%96
שלבי פרויקט התאמה לארגון ככלל, לכל פרויקט בכל ארגון שלבים הדומים לאלה שראינו. אולם, בכל ארגון מתאימים את השלבים, התהליכים, התרשימים, הנהלים, הטפסים והמושגים לצורכי הארגון. בכל ארגון נמצא שמות אחרים. דוגמאות מעטות: באגף מערכות מידע של חברת תקשורת: מפרט דרישות מערכת )ראשוני וסופי( נקרא מסמך הגדרת הפרויקט. שלבי הפרויקט נקראים: ייזום הגדרה )ייעוד הפרויקט(, תכנון, ביצוע ובקרה, סגירה. הגדרת הבעיה והמטרות, חקירה ורעיונות, בנייה, הערכה, ייצור, תפעול. מושגי, תכנוני, ביצועי, סיום. פעולות טרום חוזה, תיכון המוצר, תכנון הביצוע, בניית אב טיפוס, ביצוע שוטף, סיום.
השוואה בין ה- PMI ל- INCOSE Project Management Institute PMBOK ייזום Initiating תכנון Planning ביצוע Executing בקרה Monitor/Control סגירת הפרויקט Closing Systems Engineering Handbook version 3 Pre-concept (R&D) Concept פיתוח Development ייצור Production שימוש Utilization תמיכה Support הוצאה משרות Retirement
המכנה המשותף לכל המודלים בדיקת פתרון פתרון בעיה הגדרת הבעיה: הגדרת וניתוח הצורך הגדרת וניתוח הדרישות הפתרון: הפשטה, תכן על: תכן מפורט בחינת חלופות לפתרון, ניתוח פונקציונלי, בדיקת הפתרון: V & V T & E קונספטים לפתרון ארכיטקטורה
מבוא לניתוח דרישות
זיהוי צורך/בעיה/ פיתוח מערכת בפרויקט "תפור" טכנולוגי רעיון/סקר שוק. התוצר: מסמך צורך/משימה/קונספט מבצעי/תיפעולי )המהווה אפיון לביצוע בדיקת היתכנות(. נקרא לעיתים:.ORS Operational Requirements Statement ביצוע בדיקת היתכנות לבדיקת משמעויות: היתכנות טכנולוגית, עלויות, לוחות זמנים, משאבים דרושים, השפעות חברתיות וסביבתיות. התוצר: בחירת חלופה,RFP מספר חלופות למימוש. התוצר: מפרט דרישות פונקציונליות מערכת גרסת baseline )לפעמים נקרא אפיון פונקציונלי, או מסמך דרישות לקוח ברמת מערכת.SRD בצה"ל: דמ"צ-דרישה מבצעית(, הקצאת תקציב, הגדרת לו"ז. הערה: בתלות בסוג הפרויקט מכינים לעיתים גם מסמך דרישות תפעול.ORD מכרז, חוזה = +SOW )ORD( + SRD ******************************************************************* עדכון ה- ORS והרחבתו למסמך קונספט מבצעי/תיפעולי OCD-Operational Concept Document בנייה/פיתוח: עדכון/אישור ה- SRD, ו"תרגומו" למפרט מערכת System/Subsystem Specification-SSS )זהו מפרט טכני דרישות טכניות ברמת מערכת בשפת הלקוח(. הכנת מפרט ממשקים חיצוניים.IRS "תרגום" ה- SSS למסמכי דרישות תכן ( Description )SSDD-System/Subsystem Design בשפה של מהנדסים הן ברמת מערכת והן ברמת מרכיבי המערכת. הכנת מפרטי ממשקים פנימיים. עדכון.ORD תכן על Design( )Preliminary הכולל ניתוח פונקציונלי )לוגי( ותכן ארכיטקטורה )פיזי(. תכן מפורט Design(.)Detailed התוצר: אב-טיפוס/גרסה 1.0 אינטגרציה, בדיקות, אימות ותיקוף ניסויים ובדיקות של אב הטיפוס/גרסה 1.0 ייצור סדרתי הדרכה, ספרות תפעולית וטכנית, תפעול שוטף, תחזוקה, תמיכה, לוגיסטיקה, שדרוגים; הוצאה משרות.
לקוח נעסוק עתה ב- 4 השלבים הראשונים גיבוש הצורך, הגדרת המשימה והקונספט התפעולי. ORS Operational Requirements Statement בהמשך מורחב ל- Document OCD-Operational Concept "תרגום" חברה התרחישים התפעוליים לדרישות פונקציונליות. מסמך דרישות לקוח ברמת מערכת.SRD "תרגום" הדרישות הפונקציונליות לדרישות טכניות ברמת מערכת בשפת לקוח. SSS - System/Subsystem Specification "תרגום" ה- SSS למסמכי דרישות תכן SSDD-System/Subsystem Design Description )דרישות בשפת מהנדסים(.
אנו מבחינים בין 3 3 רמות של דרישות רמות של דרישות: לקוח - דרישות פונקציונליות/מבצעיות :SRD תאור צרכי הלקוח במונחים תפעוליים/מבצעיים. דמ"צ: תתאפשר תקשורת רציפה בין מוצב השליטה למטוסים בכל מתארי הפעולה. חברה/לקוח דרישות טכניות :SSS פירוט הדרישה המבצעית במונחים טכניים, בשפתו של הגוף הטכני של הלקוח, במונחים ברי מדידה דרישת לקוח: טווח התקשורת בקו ראייה בגובה 30,000 400 רגל יהיה חברה - מפרטי תכן/פיתוח :SSDD דרישות בשפת המהנדסים שמאפשרות הגדרה חד משמעית של תוצרי הפיתוח ובדיקתם ק"מ. מפרט פיתוחף בכניסת אות של 15 מיקר-וולט, 30% אפנון, 1000 הרץ, יתקבל יחס אות לרעש של 26db לפחות.
גיבוש הצורך, הגדרת המשימה והקונספט המבצעי/תפעולי Operational Concept, ORS, OCD ConOps=Concept of Operations.1 An operational concept is a vision for what the system is, a statement of mission requirements, and a description of how the system will be used. A set of scenarios describes how the system will be used )sometimes by defining the system s interaction with other systems). (Buede, 2009, p. 55)
Sample Operational Concepts Scenarios for an Elevator נוסע מבקש שרות. מקבל משוב שבקשתו התקבלה. מקבל איתות לגבי מיקומה של המעלית והאם היא נעה לכיוון הקומה בה הוא ממתין. מעלית מגיעה, הנוסע נכנס ומבקש להגיע לקומה מסוימת. מקבל משוב שבקשתו התקבלה ושהדלת נסגרת. מקבל מידע לגבי הקומות בהן המעלית תעצור ולגבי מיקומה של המעלית בכל שלבי נסיעתה ועצירתה. מקבל מידע שהגיע ליעדו, הדלת נפתחת אוטומטית. הנוסע יוצא. נוסע נכנס למעלית כמתואר לעיל אך נוצר עתה מצב חירום והוא איננו יכול לצאת. הנוסע מתקשר, באמצעות מערכת תקשורת פנימית הקיימת במעלית, למרכז בקרה שמקבל את פנייתו ושולח טכנאי לחילוץ. הטכנאי מגיע והמעלית מתוכננת כך שהוא מצליח ליצור אפשרות יציאה לנוסע. טכנאי צריך לבצע פעולות תחזוקה במעלית. הטכנאי נכנס למעלית ומעביר אותה למצב "תחזוקה". כל שאר המעליות ממשיכות לעבוד כרגיל אך המעלית שבמצב "תחזוקה" איננה משרתת נוסעים וכל מי שזקוק לשרות מקבל חיווי שהמעלית מושבתת זמנית. הטכנאי מסיים לתקן ומעביר את המעלית למצב פעולה רגיל..1.2.3
גיבוש הצורך, הגדרת המשימה והקונספט המבצעי/תפעולי Operational Concept, ORS, OCD הגדרת משימה - דוגמה.1 הגדרת המשימה היא בדרך כלל משפט אחד הנגזר ישירות מהצורך. SRD פונקציונלית מערכת אמינה וזולה לתקשורת דו-כיוונית של דיבור, נתונים ווידיאו בין מטוסים לבין עצמם ובין מטוסים לתחנות קרקעיות אשר תפעל בכל מזג אויר ובכל מתארי הלחימה. ב- SSS )מפרט דרישות טכניות ברמת מערכת בשפת לקוח( זה "יתורגם" ל: מערכת אמינה וזולה לתקשורת דו-כיוונית של דיבור, נתונים ווידיאו בין מטוסים לבין עצמם ובין מטוסים לתחנות קרקעיות אשר תפעל בכל מזג אויר לטווחים של עד 250 ק"מ וגובה 40,000 רגל.
שלב 2: "תרגום" התרחישים התפעוליים/מבצעיים לדרישות פונקציונליות SRD דרישות לקוח פונקציונליות ברמת מערכת Requirements are the foundation of the project. They form the basis for design, manufacture, test and operation. It is essential that a complete set of requirements be established early. The objective of requirements analysis is to identify and express requirements that state user needs and objectives.
מבוא לניתוח דרישות )המשך( System requirements cannot be established without checking their impact on lower level elements. Therefore, requirements definition is an iterative process that works both top-down and bottom-up. Once the top-level set of system requirements has been established, it is necessary to allocate and flow them down to lower level. It is essential that traceability be maintained to assure that all system level requirements are satisfied in the design.
עיקרון חשוב גם בעת פרוק הדרישות והקצאתן לאלמנטים, הלאה, גם בעת פרוק הדרישות והקצאתן למרכיבי המערכת )אלמנטים, תת המערכות, מכלולים( לתת המערכות, צריך להמשיך להסתכל על השלם. למכלולים צריך להמשיך להסתכל על השלם.
מסמך ה- SRD )דרישות פונקציונליות ברמת מערכת בשפת לקוח( SRD=System Requirements Document Capturing Source Requirements המקורות לעדכון/אישור ה- SRD בחברה לאחר שזכתה במכרז הינם בדרך כלל מסמכים של הלקוח source documents כגון: מסמך הצורך/משימה/קונספט מבצעי/תפעולי ORS מסמך ה- SRD של הלקוח )דרישות פונקציונליות ברמת מערכת; אפיון פונקציונלי; דמ"צ( החוזה כולל ה- SOW דוחו"ת, המטרה מסמכים, סיכומי דיונים, ראיונות עם נציגי הלקוח להבטיח שבחברה מבינים היטב את צרכי ודרישות ה.end-user נדרש תיאום עם הלקוח ואישורו למסמך, בדרך כלל ב: SRR=System Requirements Review הערה: בתלות בסוג הפרויקט מכינים לעיתים גם מסמך דרישות תפעול ORD
דוגמה לקטע מתוך SRD
Context Diagram תרשים "המערכת בסביבתה": טכניקה שנועדה להבטיח שלא שכחנו דרישות הנובעות מאינטראקציה והתממשקות המערכת לסביבה בה היא אמורה לפעול
מסמך הגדרת הפרויקט בארגונים בהם נהוג להכין מסמך הגדרת פרויקט הוא מתאר מה המערכת צריכה לעשות ומדוע וכולל בדרך כלל את: תיאור התפיסה המבצעית והצורך המבצעי.ORS מי המשתמשים? מה השימוש שלהם במערכת? איך ישתמשו? באיזה תנאים? תיאור הסביבה התפעולית בה תפעל המערכת )תרחישי עבודה סצנריו(. תיאור מודי הפעולה. ConOps=Concept of Operations מטרות המערכת. הדרישות הפונקציונליות ברמת על מהמערכת שתפותח או הפנייה ל- SRD. תיאור דיאגרמת מלבנים פונקציונלית ראשונית. תיאור ושרטוט ראשוני של ארכיטקטורת המערכת. ;Re-use שימוש בתשתיות קיימות, COTS-Commercial Off The Shelf פתרונות קיימים ו/או בציוד מסחרי המערכות המתממשקות למערכת, הנתונים שהם אמורות לספק )inputs( או לקבל,)outputs( ודרישות ראשוניות לגבי הממשקים למערכות האחרות. כלומר, בניתוח הצורך והגדרת הדרישות צריך להתחשב גם בשילוב ובאינטראקציה עם המערכות האחרות בסביבה בה תפעל המערכת.
שלב 3: מפרט מערכת SSS System/Subsystem Specification השלב הבא הוא "תרגום" מסמך הדרישות הפונקציונליות.SSS לדרישות טכניות ברמת מערכת בשפת לקוח SRD זהו מפרט טכני ברמת על הכולל ערכים מדידים. הכנת המסמך נעשית בד"כ ע"י צוות רב תחומי בהובלת מהנדסי מערכות. בשלב זה לפעמים בודקים את מפרט המערכת SSS בעזרת סימולציות או סימולטורים המבוססים על תרחישי )סצנריו( פעולה.
המפרטים הטכניים כל דרישה במפרט המערכת הטכני SSS צריכה להיות מתורגמת ל: דרישה)ות( במפרטים הטכניים של מרכיבי המערכת. דרישה)ות( במפרטי הבדיקות. להשתמש ב- shall )דרישה מחייבת(, What ולא.how לגבי ניסוח הדרישות: should )המלצה(, may )רשות(. יש לפרק את הדרישות במפרטים הטכניים מרמת המערכת עד רמת: עבור חומרה Item.Configuration עבור תוכנה Component.Computer Software כל דרישה טכנית צריכה לעמוד בפני עצמה, לא בסתירה לדרישות אחרות, ניתנת למימוש על ידי פונקציה אחת או מרכיב אחד של המערכת וניתנת לבדיקה )כמותית( על ידי בדיקה אחת. במקרה של סתירות ניתן לרשום: TBR To Be Resolved TBD To Be Determined
דוגמה 1 לפירוק דרישות Requirements Allocation המשקל הכולל של רכב חלל מוכתב ע"י המשקל שיכול לשאת רכב השיגור המכניס את רכב החלל למסלולו. הכתבת משקל זה מאלצת דרישות משקל על תת מערכות של רכב החלל כמו למשל: תת מערכת הייצוב ובקרה. תת מערכת הטלמטריה )החלק בו נמצאים מכשירי המדידה והציוד לשידור תוצאות המדידות(. תת מערכת אספקת הכוח.
דוגמה 2 לפירוק דרישות Requirements Allocation דוגמה: קיים אילוץ על ה- MTBF של המערכת המכתיב אילוצי MTBF על תת המערכות. SYSTEM MTBF=500hrs Failure rate=λ λ =1/500=0.002 SUB 1 MTBF=2500hrs λ =0.0004 SUB 2 MTBF=2000hrs λ=0.0005 SUB 3 MTBF=1667hrs λ=0.0006 SUB 4 MTBF=2000hrs λ=0.0005
הערה התהליך כולו איטרטיבי. למשל: אם בשלבים הבאים, תוך כדי הקצאת/פירוק הדרישות לרמות )level( נמוכות יותר )allocation/decomposition( או בעת שלבי התכן אנו מגלים ששכחנו משהו או שיש בעיה עם איזושהי דרישה, ניתן לחזור ולעדכן את ה- SRD ומפרט המערכת. כל שינוי בפרויקט מחייב עדכון מסמכי הדרישות.
הגדרה: Requirements Analysis המונח Requirement Analysis מתייחס לתהליכים הבאים: זיהוי וניסוח הדרישות Requirements( )Capture the מהמערכת וכתיבת מפרט דרישות מערכת SRD )פונקציונלי, לא טכני( ומפרט מערכת SSS )טכני עם ערכים ברי-מדידה(. ניסוח הדרישות צריך להיות מושפע מהפתרון האפשרי משהו שאינו בר-השגה(. )לא נדרוש תיקוף הדרישות בדיקה שאכן כל דרישה עונה על צורך של הלקוח/המזמין. בדיקה שמימוש כל אחת מהדרישות לא יפגע באופטימיזציה המערכתית )למשל לא נדרוש אמינות של מליון שעות, סבירות(. זה יגרום לעלויות לא בדיקה מעמיקה ומקיפה שאנו מבינים היטב את הדרישות ושלא שכחנו שום דבר.
מעקב דרישות Traceability
דוגמאות למספרי דרישות בפרויקטים 150 1500 5000 20000 200000 פרויקט קטן מאוד פרויקט קטן פרויקט בינוני פרויקט גדול פרויקט גדול מאוד כרטיס אלקטרוני מכשיר טלפון מוצר מערכתי מערכת מורכבת מערכת תקשורת ארצית
מעקב דרישות - traceability הצורך כל דרישה במסמכי הצורך ORS צריכה להיות מתורגמת לדרישה במפרט הדרישות הפונקציונליות SRD כל דרישה במפרט הדרישות הפונקציונליות SRD צריכה להיות מתורגמת לדרישה במפרט המערכת הטכני SSS כל דרישה במפרט המערכת הטכני SSS צריכה להיות מתורגמת לדרישות במפרטי התכן SSDD של המערכת ושל מרכיבי המערכת כל דרישה במפרטי התכן SSDD צריכה להיות מתורגמת לדרישה במפרטי הבדיקות של המערכת ומרכיבי המערכת ניהול ומעקב הדרישות נעשה במאגרי נתונים ממוחשבים database ומטריצות המעקב נעשות בדרך כלל בעזרת כלי תוכנה מסחריים )דוגמה בשקפים הבאים(.
דוגמה למערכת לניהול דרישות - DOORS דוגמה לדו"ח - עקיבות
דוגמה למערכת נוספת לניהול דרישות )NICE )בשימוש IBM של Focal Point http://www.ibm.com/developerworks/offers/lp/demos/summary/r-focalpoint.html
-ilities
ilities דרישות כלליות נוספות שיש לשלב במפרטים - אמינות R=MTBFX/(MTBF+MTTR) - Reliability Rsys=R1XR2XR3 במידה ויש דרישה לגבי אמינות מערכת R זה מיד מאלץ דרישת אמינות מהאלמנטים )לפחות שורש של R(. לדוגמה, ממערכת לה שני אלמנטים נדרשת אמינות של 0.81 אמינות כל אחד מהאלמנטים צ"ל 0.9 לפחות. זמינות Availability זמינות ראשונית )מועד אספקה( ושוטפת )חלק הזמן בו פעלה בלי להיות מושבתת(. time A=MTBF/(MTBF+MDT) MDT-mean down תחזוקתיות Maintainability ניתנת לתחזוקה מונעת ומתקנת בשטח ובמעבדה; יכולת לתחזק: )ציוד בדיקה סטנדרטי או ציוד בדיקה ספציפי ידני או אוטומטי,ATE/FTE חלפים, ספרות טכנית, תמיכת הספק(. בדיקתיות Testability ניתנת לבדיקה, יכולת בדיקה עצמית Test( )BIT=Built In תאימות Compatibility פועלת היטב גם בסביבת מערכות אחרות. למשל,.EMC הסתגלות Adaptability או - Changeability ניתנת בקלות לשינויים; יכולת לתפקד בתנאים שהשתנו )בניגוד למערכת קשיחה שאינה מסוגלת לתפקד במקרה של שינוי(. אחידות Commonality דמיון למערכות אחרות בארגון )תוכנה חדשה לניהול מלאי דומה לתוכנה קיימת לניהול רכש(. הישרדות Survivability במערכות צבאיות: יכולת לתפקד בתנאי לחימה. פשטות Simplicity פשוטה לתפעול ותחזוקה, קלה להטמעה וקליטה. ידידותיות Friendliness מערכת ידידותית למשתמש. חסינות Robustness עמידה בתנאי סביבה ובפני טעויות משתמשים ו"רעשים" אחרים. לדוגמה, רכב שטח צריך להיות רובוסטי )ובעצם כל רכב(. בטיחות Safety בטוחה לתפעול ולתחזוקה.
סוגי דרישות
סוגי דרישות 1. דרישות פונקציונליות Functional Functional states what the item is to do. Must have an action (verb) and an object (noun). e.g. track (verb) targets (noun) 1.1 Input requirement: The elevator shall receive calls from all floors of the building. 1.2 Output requirement: The elevator shall indicate to a prospective passenger that he/she has successfully called the elevator. 1.3 External interface requirement: The elevator shall use a standard phone line from the building for emergency calls.
דוגמה לקטע מתוך SRD
סוגי דרישות 2. דרישות טכניות Performance For a given function, states how well that function is to be performed. Should be stated in quantitative terms. The transmitter shall provide full power with an amplitude variation of not greater than +/- 0.5 db over the temperature range 0 to +40 degree C. The contractor shall complete all maintenance actions within 24 hours of receipt of a Maintenance Request. The elevator system s software shall be written in C++ The elevator system s CPU shall be Pentium 4. המשקל לא יעלה על 900 גרם. בכניסת אות של 15 מיקר-וולט, 30% אפנון, 1000 הרץ, יתקבל יחס אות לרעש של 26db לפחות.
סוגי דרישות External Technical Interface Requirements.3 The interface between the router and the modem shall comply with EUROCOM D/1 (2- wire, 16 kbps). Interfaces to BEZEQ shall be either in nonsecure analogue voice into the public switched telephone network or in FSK data. The equipment shall be mountable in standard 19 inch cabinets.
דוגמה דוגמה סוגי דרישות 4.State/Mode State (a condition, operational state) :1 למערכת יהיו מצבים 3 on/off/standby - למערכת 2: דיאגרמת מצבים: יש 'מזג אוויר' 3 מצבים גשם מעונן, בהיר, גשם מעונן בהיר במערכת טכנולוגית - בכל מצב יכולים להיות מספר מודי עבודה.
סוגי דרישות (המשך).State/Mode 4 Mode עבודה) (אופן a distinct operating capability of the system during which some or all of the system s functions may be performed to a full or limited degree. Full detection capability mode דוגמה 1: מודי עבודה אפשריים של מכ"מ: לא יגלה את כל סוגי הטילים אבל יהיה יותר רגיש לאלה שכן Reduced detection capability Automatic tracking mode Offline diagnostics mode (maintenance mode) Reduced resolution display mode The radar shall also have an autonomous mode. דוגמה 2: מודי עבודה של טלפון נייד: קול, הודעות,SMS וידיאו דוגמה :3 non-operational. The system shall have 3 modes: full operation; degraded operation;
סוגי דרישות 5. עמידה בתנאי סביבה Environmental דו כיווני: השפעת המערכת על הסביבה )למשל, הקרנה לסביבה( והשפעת הסביבה על המערכת )למשל, עמידות בפני קרינה(. The radar shall be able to fully operate in temperatures of up to 44 degree Celsius plus solar radiation in combination of humidity of 20-90 percent. The equipment shall withstand without damage shock pulses of 20kg amplitude, 1 second duration, and half sine wave waveform.
סוגי דרישות Resources.6 State the limits of consumption or use of externally provided resources such as: electrical power cooling water computer memory computer processing capability Consumables Labor etc.
סוגי דרישות Physical.7 מידות, משקל, צורה, נפח, צבע וכד'. The depth of the equipment shall not exceed 530mm measured from the to the No LRU shall have a mass exceeding 15KG. The total volume occupied by the equipment shall not exceed 0.5 cubic meter.
סוגי דרישות Other Qualities.8 Reliability Availability Survivability Maintainability Transportability Compatibility Reusability Etc.
סוגי דרישות Design.9 Direct the design by inclusion (build it this way), or exclusion (don t build it this way).
סוגי דרישות Process Requirements.10 דרישות שמתייחסות למשל ל: תהליכי/שיטת הפיתוח ו/או ניהול הפרויקט תהליכי ייצור תמיכה במערכת תהליכי/שיטת בדיקות דרישות אבטחת איכות הכוונה למסמכים מחייבים )למשל, )DoD-STD-2167A וכד'
מה נדרש מדרישה? נכונות Correctness שלמות - Completeness עקביות Consistency/coherence בהירות - Clarity חד משמעותיות Non-Ambiguity ניתנת למעקב Traceability ניתנת לבדיקה ואימות Testability ניתנת ליישום Feasibility ייחודיות - Singularity
QFD
QFD Quality Function Deployment תרשים להצגת דרישות הלקוח, יחסי הגומלין ביניהן, ותרגומן לדרישות פונקציונליות וטכניות. נועד גם להבטיח שכל דרישות הלקוח אכן נלקחו בחשבון ותורגמו לדרישות פונקציונליות וטכניות. במקומות מסוימים מכנים בשם QFD את כל התהליך של תרגום קול/צורכי הלקוח למאפיינים/דרישות/שפת המהנדסים. כלומר את התהליך של תרגום הצורך לדרישות פונקציונליות ותרגום הדרישות הפונקציונליות לדרישות טכניות. התרשים מכונה לעיתים "בית האיכות" HOQ House Of Quality
דוגמה: מכונית QFD מהירות מקסימלית דרישת לקוח )בשורה ראשונה של 200 )what דרישות פונקציונליות )נכתבות אנכית בעמודות קמ"ש. :)features מנוע גדול דרישה טכנית )נכתבת ב- much :)how 2 מקדם גרר דרישה טכנית: )התנגדות האוויר( 0.31 משקל נמוך דרישה טכנית: נמוך. 1450 ק"ג לכל היותר. ליטר.
דוגמה: מכונית )המשך( QFD נוחות דרישת לקוח )בשורה שנייה של )what בין 10 מובילים בעולם. דרישות פונקציונליות )נכתבות אנכית בעמודות :)features ישיבה נוחה דרישה טכנית: מנוע שקט דרישה טכנית מרווח רגלים חצי מטר )נכתבת ב- much :)how 30db משענות ראש דרישה טכנית: 5, מחומר סופג
דוגמה: מכונית )המשך( QFD המטריצה מראה את מידת התרומה של הדרישה הפונקציונליות )feature( למימוש דרישת הלקוח :)requirement( שני עיגולים: תרומה גבוהה. עיגול אחד: תרומה נמוכה. אף עיגול: feature שורת :Benchmark לא רלבנטי לדרישת הלקוח. השוואה למתחרים.
דוגמה: מכונית )המשך( QFD על ה"גג" - מטריצת קורלציות בין הדרישות הפונקציונליות )features( לבין עצמן: שני עיגולים: קשר חיובי חזק דרישה חיונית מאוד אם למשל, features 3 תומכות באותה דרישה לוקחים את הקומבינציה בעלת יחס תועלת/עלות הכי גבוה. עיגול אחד: קשר חיובי חלש דרישה חיונית שני X: דרישות מנוגדות חזק מחייב.tradeoff דרישה לקוח: נוחות. פונקציונלית: מקדם גרר נמוך. דרישה מנוגדת דרישת לקוח: נוחות. פונקציונלית: גג נפתח. X אחד: דרישות מנוגדות חלש. שום סימון אין קשר, לא רלבנטי.
ניתוח פונקציונלי
היכן אנחנו? בדיקת פתרון פתרון בעיה עד עכשיו עסקנו בהגדרת הבעיה: הגדרת וניתוח הצורך הגדרת וניתוח הדרישות עכשיו אנחנו מתחילים לעסוק בפתרון: הפשטה, בחינת חלופות לפתרון, קונספטים לפתרון תכן על: תכן מפורט ניתוח פונקציונלי, ארכיטקטורה בהמשך הקורס נעסוק בבדיקת הפתרון: V & V T & E
"תרגום" מהו ניתוח פונקציונלי? הדרישות לפונקציות. פונקציה = מה זה עושה? ביטוי שכולל פועל ושם עצם. A function is a task, action, or activity that must be performed to achieve a desired system behavior. דוגמאות לפונקציות: כסא נושא משקל. דלת סוגרת מעבר. מברג מפעיל מומנט. דוגמה לפירוק פונקציות לתת פונקציות: מכונית מסיעה אנשים. מנוע ממיר אנרגית דלק לאנרגיה קווית של הבוכנות. תת מערכת הבוכנות ממירה תנועה קווית לתנועה סיבובית. גל ארכובה מעביר את התנועה הסיבובית לגלגלים.
המטרות של ניתוח פונקציונלי הבנה מעמיקה ויסודית של הבעיה. חשיבה יצירתית שהתוצר שלה מגוון רחב של רעיונות שאינם מוכתבי פתרון. ניתוח פונקציונלי מעורר יצירתיות. אין ל"קפוץ" מהדרישות לפיתרון הטכני אלא לתרגם תחילה את הדרישות לבעיות בסיסיות ואותן לפונקציות כשכל זאת נעשה מבלי להתייחס לפתרון אפשרי. הגדרת הפונקציות העיקריות נקראת לעיתים הפשטה!
כלים לניתוח פונקציונלי אחד מהכלים הנפוצים לביצוע ניתוח הוא תרשים מלבנים הנקרא: פונקציונלי FFBD Functional Flow Block Diagtam The objective of Functional Analysis/Allocation is to create a functional block diagram that can provide the foundation for defining the system architecture through the allocation of functions and subfunctions to hardware/software and operations. כלים נפוצים אחרים: תרשים/דיאגרמת זרימה. תרשים עץ פונקציות.FAST
שלב 1 פירוק הצורך והבעיה למספר בעיות בסיסיות, בלתי תלויות זו בזו, ללא תיאור הפתרון, אשר מכסות את הצורך במלואו.
שלב 2 תרשים ניתוח זרימות/תרשים זרימה פונקציונלי FFD - Functional Flow Diagrams תרשים רב שכבתי המתאר את ההיררכיה של הדרישות הפונקציונליות. בשורה העליונה- כל הפונקציות המערכתיות לאורך כל מחזור החיים. הפונקציות
FAST: Functional Analysis System Technique הצגה גרפית של הפונקציות, תת הפונקציות והקשרים ביניהן. לרוב משורטט כעץ. הסעת אנשים המרת דלק לאנרגיה קווית המרת תנועה קווית לסיבובית העברת תנועה סיבובית לגלגלים הכנסת אוויר הצתת תערובת
העץ יכול להיות גם אופקי כמובן גילוי עקיבה העברה לטייס העברה לקרקע זיהוי חדירה העברת מידע המשימה
דוגמה לתרשים/דיאגרמת זרימה
ממשקים Interfaces
ממשקים Interfaces ישנם ממשקים שהינם פיזיים בלבד וישנם ממשקים שהם פונקציונליים ופיזיים. תכנון הממשקים מלווה את הפרויקט בכל השלבים מהגדרת הדרישות ושלב גיבוש הקונספט, דרך תיכון העל והתיכון המפורט. ממשקים שהינם פונקציונליים ופיזיים: ההיבט הפיזי - מחברים חשמליים )קונקטורים( וכבלים: כמות, כמות פינים, סוגי פינים, סיכוכים. ההיבט הפונקציונלי העברת נתונים ואותות חשמליים: Data אותות, תזמונים, נתונים Commands פקודות, בקרה, אותות לוגיים ממשקי וידיאו Power אספקות, אדמות ממשקים שהינם פיזיים בלבד - סוגי חומרים, לחצים מידות, משקלים, אטימות נק' עגינה-מיקום, חוזק, טמפ' ממשקים טרמיים מעבר נוזלים ו/או אוויר ממשקי תוכנה חיבורים מיכניים מיקום, הודעות בין מרכיבי המערכת, פרוטוקולים, תקשורת ממשקים נוספים ממשקים אופטיים מפתחי כניסה/יציאה, שדות ראייה ממשקי קרינה סוג,
N 2 Chart
N 2 הסבר עקרוני שיטה לזיהוי, הגדרת, תיכון וניתוח ממשקים פונקציונליים ופיזיים. באלכסון רושמים את מרכיבי המערכת במטרת התרשים(. )פונקציונליים או פיזיים, תלוי בשאר המשבצות רושמים את הממשקים/אינטראקציות/קשרי גומלין/זרימת נתונים/כניסות-יציאות בין המרכיבים הרשומים באלכסון. למשל: הסימן F1 F2 מתאר זרימת נתונים מ- F1 מתאר זרימת נתונים חזרה )פידבק( בין F2 ל- F1. הסימן ל- F2. F2 F1 כאשר משבצת מסוימת ריקה מתואר ע"י המשבצת. שאלה: אין זרימת נתונים בכיוון האמור להיות האם זה מחייב שאין ממשק בין שני מרכיבים אלה?
א) ב) ג) תרגיל אחת ממערכות הקשר במטוס נוסעים מורכבת מ- 3 אלמנטים: ) מכשיר הרדיו עצמו )מקמ"ש=מקלט-משדר( המותקן בתא מכשירים בבטן המטוס, ) מגבר הספק המותקן בסמוך לרדיו והמשמש להגברת הספק השידור במקרה הצורך ו- ) קופסת הפעלה המותקנת בפנל מול הטייס בקוקפיט )תא הטייס( והמשמשת לכיבוי/הדלקת הרדיו, כיבוי/הדלקת מגבר ההספק, כיוון ערוץ התקשורת )תדר השידור/קליטה( ומתן חיווי לטייס על תקלות ברדיו ועל תקלות במגבר ההספק. שרטט דיאגרמת N בריבוע לתאור ממשקי המערכת.
פתרון הודעה על תקלה אות שידור )חלש( רדיו הודעה על תקלה קופסת הפעלה מגבר הספק פקודת כיבוי/הדלקה פקודת כיבוי הדלקה כיוון תדר שידור/קליטה
מינימיזציה של מספר הממשקים ממשקים הינם מקור לתקלות; ככל שיש יותר ממשקים בין מרכיבי המערכת כך התיכון מסובך יותר. ממשק הינו מקור לטעויות תיכון העלולות לפגוע באינטגרציה/שילוב מרכיבים ובכך לפגוע בפעולת המערכת. פחות ממשקים = פחות מקורות לטעויות, וקשיי אינטגרציה. סיבוכים, תקלות
תכן על )המשך( תכן הארכיטקטורה של מערכת
היכן אנחנו? בדיקת פתרון פתרון בעיה עד עכשיו עסקנו בהגדרת הבעיה: הגדרת וניתוח הצורך הגדרת וניתוח הדרישות עכשיו אנחנו מתחילים לעסוק בפתרון: הפשטה, בחינת חלופות לפתרון, קונספטים לפתרון תכן על: תכן מפורט ניתוח פונקציונלי, ארכיטקטורה בהמשך הקורס נעסוק בבדיקת הפתרון: V & V T & E
שלב הגדרת/תכן הארכיטקטורה אחרי שלבי ניתוח הדרישות והניתוח הפונקציונלי מגיע שלב הגדרת הארכיטקטורה וסינתזה. תהליך העבודה ב- 3 תתי השלבים הינו איטרטיבי.
Architecture Definition ארכיטקטורה של מערכת = בחירת אלמנטי המערכת הפיזיים, מאפייניהם ואופן סידורם; הקצאת הפונקציות )מהניתוח הפונקציונלי שבשלב הקודם( לאלמנטים פיזיים. תזכורת: - אלמנטים רמה אחת מתחת למערכת. בהמשך, מבצעים allocation לפי ההיררכיה ומגדירים את הארכיטקטורה של האלמנטים, תת המערכות, המכלולים וכן הלאה. The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. DoD Integrated Architecture Panel, 1995, based on IEEE STD 610.12
דוגמאות לתרשימי ארכיטקטורה
סוג תרשים נפוץ דיאגרמת מלבנים כמו ה- FFBD שראינו אלא שכל מלבן לא מייצג פונקציה אלא,Configuration Item( CI "קופסת" חומרה או מודול תוכנה(.
En Route ATC Analog Voice Communications System Architecture
רמות היררכיה של מערכת
דוגמאות לארכיטקטורה של רשתות
הגדרת מילים חדשות בשפה החדשה שלושת תתי שלבים הגדת הדרישות, ניתוח פונקציונלי, תכן ארכיטקטורה מכונים בשם הכולל: הגדרת מערכת. שני תתי השלבים ניתוח פונקציונלי ותכן ארכיטקטורה מהווים את 'תכן על'.preliminary design הניתוח הפונקציונלי נקרא לעיתים 'תכן לוגי' ותכן הארכיטקטורה נקרא לעיתים 'תכן פיזי'. הערה: במקומות מסוימים נהוג לראות גם את תכן הממשקים כתת שלב בתכן העל.
סינתזה שלב הסינתזה מבוצע במקביל לתכן הארכיטקטורה. נניח שיש לנו בכל רמה )מערכת, אלמנטים, תת מערכת, מכלולים, מרכיבים/"קופסאות"( מספר פתרונות אפשריים. צריך למצוא את הצרוף האופטימלי. בודקים את כל הצרופים האפשריים לפי קריטריונים כמו ביצועים, עלויות, לו"ז, פשטות, איכות, אמינות וכד'.
דוגמה 1 לסינתזה: מערכת לתקשורת נתונים דרישה פונקציונלית ריבוב אפנון וגילוי מיתוג/ניתוב הצפנה עיבוד אותות בקרה הקלטה שידור אפשרויות ל- design ריבוב בתדר D11 ריבוב בזמן D12 D21, D22 D31, D32, D33 D41, D42 D51, D52, D53 D61, D62 D71, D72 D81, D82 מס' האפשרויות: 576=2*2*2*3*2*3*2*2 ברור שלא ניתן לבחון כה הרבה ולכן בשלב ראשון מתבצעת פסילה על הסף של חלופות שאינן מתאימות תרגיל: מהו מס' האפשרויות אם יש 3 חלופות תכן לכל דרישה פונקציונלית? 3*3* 3=6561
דוגמה 2 לסינתזה: מערכת תקשורת מהירה חלופות אפשריות ברמת מערכת למימוש הדרישה: ADSL תקשורת רדיו ATM תקשורת בכבלים סיבים אופטיים תקשורת לווינים עבור כל אחת מ- 5 החלופות הנ"ל יש חלופות שונות למימוש )למשל, 1.5Mאו - ADSL 4M(. צריך להשוות בין כל החלופות האפשריות.
טכניקה להצגת החלופות: מפה מורפולוגית דוגמה: מפה מורפולוגית של פטיש )אפשרויות )2X5X4X4X2=320
טכניקה להצגת החלופות: מפה מורפולוגית אפשרות אחרת על בסיס אותו רעיון: מכינים טבלה בה העמודות )או השורות( )המשך( הן הפונקציות. מתחת לכל פונקציה רושמים את כל האפשרויות למימושה. ליד כל אפשרות רושמים "ציון" על בסיס זמינות הטכנולוגיה למימוש והסיכון הפוטנציאלי. תחילה מחפשים את הקומבינציות עם סכומי הציונים הגבוהים ביותר ובהמשך מפעילים שיקולים נוספים לבחירת הקומבינציות אותן נבחן לעומק. בוחרים את החלופה )קומבינציה( הנבחרת. עבור החלופה שנבחרה משרטטים תרשים ארכיטקטורה.
דוגמה: מערכת למניעת הירדמות בנהיגה 108 קומבינציות, מתוכן בחרנו 3 קונספטים לבחינה זיהוי עייפות תנודות ראש )4( מצב אישוני עיניים )5( מצב אחיזה בהגה )3( שילוב )3( התראה הפעלה חישה צפצוף חזק )4( הרעדת המושב )3( אוט' עם התנעה )5( חיישן תנודות )3( אור מהבהב )5( אוט' מעל מהירות )4( חיישן לחץ )4( ידנית )2( מצלמה )5( פונקציה תומכת 1.. פונקציה תומכת 2
אינטגרציה
מהי אינטגרציה? מטרת האינטגרציה היא לשלב ולבדוק את הממשקים בין: כל אחד ממרכיבי המערכת למרכיבים האחרים המתממשקים אליו )אינטגרציה פנימית(. בין המערכת למערכות חיצוניות המתממשקות אליה )אינטגרציה חיצונית(. מאמץ האינטגרציה נמשך מהתחלת תיכון העל ועד לסיום הבדיקות ומחייב גם תיאום בין צוותים, אנשים וארגונים.
יעדי תהליך האינטגרציה )שילובים( בדיקת תקינות הממשקים שבין החלקים. בדיקת הפעולה המשותפת של החלקים. פתיחת מעטפת הביצועים של המערכת. מציאת שגיאות תכן. o o o o
ממשקים Interfaces )חזרה( סוגי ממשקים חשמלי מחברים חשמליים )קונקטורים( כמות פינים, סוגי פינים, סיכוכים Power אספקות, אדמות Data אותות, תזמונים, נתונים Commands פקודות, בקרה, אותות לוגיים ממשקי וידיאו תוכנה וכבלים: כמות, מיקום, סוג, הודעות בין מרכיבי המערכת, פרוטוקולים, תקשורת פיזי - חיבורים מיכניים ממשקים נוספים סוגי חומרים, לחצים מידות, משקלים, אטימות נק' עגינה-מיקום, חוזק, טמפ' ממשקים טרמיים מעבר נוזלים ו/או אוויר ממשקים אופטיים ממשקי קרינה מפתחי כניסה/יציאה, שדות ראייה
תהליך האינטגרציה תהליך האינטגרציה, בניית המערכת והבדיקות מתבצע מלמטה למעלה.bottom-up בודקים, מאמתים ומתקפים כל מרכיב בנפרד. מחברים שני מרכיבים ובודקים באם ביחד הם מאומתים ומתוקפים. במידה וכן מוסיפים מרכיב שלישי וכך הלאה עד שמגיעים לרמת מערכת. לעיתים מקימים קבוצות עבודה רב-תחומיות.IFWG Interface Working Group לכל "קופסה" מכינים.ICD Interface Control Document לצורך ההכנה נדרש שת"פ ותיאום בין צוותי הפיתוח השונים. בפרויקטים מורכבים, נתוני הממשקים נשמרים במערכת מידע/בסיס נתונים.
גישות לתהליך השילובים )אינטגרציה( הגישה ההיררכית מנוהלת על פי עץ המערכת מלמטה למעלה. מתאימה יותר למערכות בהן קיימים סיכונים בשילוב ה"קופסאות" )המרכיבים הפיזיים(. הגישה התפקודית - פונקציונלית מנוהלת על פי תפקידים. פעולה חלקית של המערכת מתקבלת כבר בשלבים המוקדמים של תהליך האינטגרציה. מתאימה יותר למערכות בהן קיימים סיכונים בתפקידים של תתי מערכות/מכלולים.
ויש גם מקרים של אינטגרציה Top-Down מסמלצים את כל המרכיבים לשילוב ובודקים את פעולת המערכת המתקבלת. אם מאומת ומתוקף כנדרש אזי...... בהדרגה מחליפים כל יחידה מסומלצת במרכיב אמיתי ובכל פעם בודקים שהמערכת פועלת כנדרש. ממשיכים עד שכל המערכת מורכבת מיחידות אמיתיות.
מתי להתחיל את האינטגרציה לכאורה לאחר גמר תיכון מפורט ובניית דגמים/אבי טיפוס. אולם כידוע תהליך האינטגרציה הינו מורכב, ארוך מאוד ובעייתי. אם מתגלה בו בעיה, צריך לחזור הרבה אחורה. לכן, צריך להתחיל את האינטגרציה מההתחלה. במיוחד יש להתחיל מההתחלה את תכנון האינטגרציה לרבות הכנה מראש של כל התשתיות הדרושות כדי למנוע עיכובים.
אתגרים בתכנון וניהול שילובים התהליך ממושך ומורכב לניהול )ריבוי דיסציפלינות ומומחים(. לעיתים פתרון בעיות גורר תקלות בלתי צפויות במקומות בלתי צפויים. יש לתכנן היטב את התשתיות הנדרשות כגון: מעבדות ושטחים, כ"א ייעודי מיומן ובזמן, דגמים, צב"דים, סימולטורים, סימולציות, ספקי כוח מיוחדים ואמצעי שינוע. יש להכין מראש את ההוראות, התכנון ומערכי עבודה. התהליך רגיש לסדר הגעת החלקים ומותנה בבשלות ומוכנות החלקים המגיעים לאינטגרציה.
בדיקות, אימות ותיקוף
בדיקת פתרון בדיקת הפתרון פתרון בעיה הבעיה: הגדרת וניתוח הצורך הגדרת וניתוח הדרישות הפתרון: הפשטה, תכן על: תכן מפורט בחינת חלופות לפתרון, ניתוח פונקציונלי, בדיקת הפתרון: V & V T & E ארכיטקטורה )בדיקות פיתוח DT&E קונספטים לפתרון ובדיקות בשטח )OT&E
Verification and Validation אימות Verification בדיקות באם המערכת על כל מרכיביה וממשקיה עומדת בדרישות שהוגדרו במפרטים. Did you build it right? תיקוף Validation בדיקות באם המערכת אכן עונה על צורכי הלקוח )האם הדרישות נכונות?( Did you build the right thing? לפעמים מגדירים: Qualification (QUAL)=Verification+Validation
Verification (1) תזכורת: עמידה במפרטים right? Did you build it תוכנית בדיקות Test and Evaluation Master Plan )TEMP( מלווה את הפרויקט לכל שלביו. Test Plan T & E בדיקות מבוצעות בתום כל שלב לפני מעבר לשלב הבא, בתום בניית אב-טיפוס ובמהלך הייצור הסדרתי.
Verification (2) מהימנות תוצאות מדידה: בדיקות חוזרות כעבור זמן.test-retest בדיקות בתנאים שונים. בדיקות על ידי שני בודקים לפחות.
סוגי אימות Verification Simulations הפעלת מודל של המוצר תוך מדידת תוצאות. Analysis הוכחה ע"י ניתוח וחישוב. למשל, by similarity מבוצע כאשר בדיקה בפועל יקרה מאוד או לא ריאלית. Demonstrations הפעלת המוצר ותצוגה של ביצועים ו- output כתגובה ל- input )בד"כ ללא צורך במכשור וצב"ד( כדי להראות תפקוד תקין. למשל, תצוגה על צג מחשב או מחוון או זמן תיקון.MTTR Tests בדיקות במעבדה בתנאים מבוקרים בעזרת צב"ד ספציפי וסטנדרטי תוך ביצוע מדידות ורישום תוצאות. Inspections בחינת תכונות כמו צבע, משקל וכד' )בד"כ, תכונות שניתן לבודקן בראייה, השוואה חזותית של הפריט לשרטוטים ותעוד(. בדיקות קבלה acceptance tests בשיתוף הלקוח )מושג זה מתייחס בהרבה מקרים לבדיקות שחרור של פריטים בסדרת ייצור. יש מקומות שהכוונה בשם זה היא לחלק האחרון של בדיקות ה- validation (. Qualification בדיקת עמידת האב טיפוס בתנאי סביבה: טמפרטורה, רעידות, תאוצות, שוק, גשם, לחות ועוד אבלואציה מבצעית בדיקות בפועל בסביבת התפעול האמיתית. OT&E Certification בדיקה על ידי גורם חיצוני בתוכניות אזרחיות. למשל, מתן תו UL למכשירי חשמל בארה"ב..1.2.3.4.5.6.7.8.9
בדיקות עמידה בטמפרטורה ובהרעדות הבדיקה הנפוצה ביותר: בתום בניית האב-טיפוס חלק מהבדיקות להוכחת עמידת אב הטיפוס בדרישות המפרט. בקו הייצור בהרכבה. זוהי בדיקת screening תהליכים נפוצים לסימולציה של הסביבה: Environmental Stress Screening ESS משנים את הטמפ' HASS ובו זמנית מרעידים בצירי X לזיהוי תקלות ובעיות ו- Y Highly Accelerated Stress Screening משנים את הטמפרטורה ובו זמנית מרעידים ב- 3 צירים. )לחוד וביחד(
מבנה מפרט בדיקות מעבדה - דוגמה כללי מטרת/מהות הבדיקה. ציוד נדרש )צב"ד סטנדרטי וספציפי, כלים, תוכנות, כבלים, ציוד מיוחד(. ה- CIs הנבדקים. Set-up הוראות הרכבת מערך הבדיקה כולל שרטוטים. מהלך הבדיקה )הוראות בדיקה, סדר פעולות, מס' חזרות(. טופס רישום תוצאות כולל עמודות לתוצאות דרושות ותוצאות נמדדות. הנחיות למקרה של כישלון בבדיקות. אפשרויות: חזרה על הבדיקה, ניתוח מערך הבדיקה לגילוי טעויות, ניתוח התכן, שינוי המפרט ובקשת waiver מהלקוח.
מבנה מפרט בדיקות ציוד מוטס - דוגמה כללי מטרת/מהות הבדיקה תצורת המטוס תצורת הציוד הנבדק מהלך הטיסה הוראות לטייס/מפעיל הציוד הנבדק התחנה הקרקעית תצורה, ציוד, הוראות בדיקה, טפסים תחקור הטייס/מפעיל והצוות בתחנה הקרקעית אופן פענוח נתונים וטלמטריה
Validation תזכורת: Did you build the right thing? תיקוף החומרה והתוכנה מתבצע במקביל לאינטגרציה מלמטה עד לאב-טיפוס המלא. מתבצע בסביבת ההפעלה של המערכת בסימולציה או ב- Mock-up (. בשיתוף נציגי הלקוח. )בפועל,
מודל ה- V לתיאור שלבי פרויקט מו"פ Define User Needs Validation/Operational Test שדה System Operational Verification Define System Requirements Validation/Test מעבדה System Performance Verification Allocate System Functions to Subsystems Validation/Test מעבדה Verification of Subsystems Detail Design of Components הקפאת תכנון Test מעבדה Verify Components